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PKI,:BASEp_CLI^^ 

BACKGROUND 

. relates to public-key infrastructure 
This disclosure relates y 

o n / ^prver authent icat ion . 
(PKI) -based client/servei a 

e^cpanding popularity of rte Internet, especially 
Woria Wiae «e., .as lured .any people and .u.lnessee 
L t.e real. o. networ. — atlons. ..ere .a. .een 
„dln. .ro„t. m t.e trans..lon o. con.r.ntr 
„..o„ cer t.e.e „et«r.e. a oon.e^ence, t.e re 

mcreasln. need .or security In — 
.„ternet. in particular, t.ere is a crltrcal nee « 
„ed approac.es to ensuring t.e con.ident.alrty 
nrivate information. 

•r.r-Tnriina UNIX and Microsoft 
Many operating systems, including UN 

.a security protocol implemented through a 
Windows™, support a security p . ' the 

,,,.,aes authentication and data privacy over 
internet. However, SSL implementation has so.e 

The SSL 1.0 provides server authenticatron 
disadvantages. The SSL i f 

. ..t not client authentication. The SSL 3.0 — 

„echanis.s .or client authentication hut re^rres storage 
and management of client certificates. 

por exan^le, Web browsers that support the 
.he user of connecting to a site with an unlisted 
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ce.t..icate. u„U..ea ce.tUicate siee ...e.s .o . site 

.... a ce.U.ica.e si.ne. .V a .e.UUca.e a...o.it. no. . 

n • ^ aurh as CyberTrust or VeriSxgn. m 
the authority trust list such as Cy 

■ c hhf- user's certificate to be 
this case, the browser requires the user 

' 1= ' 1 1 oh The browser 

placed into the client cartaficate list. 

. ^4= t-vi-ic. rertificate every 
further requires the selection oi this 

,l,e a connection is ^ae to the we. server. 

,,,lie-Key infrastructure (PKI. is a combination 
software, encryption technologies, and services that 
,,..,aes security for co^unicatlons and business 
« ransactions over public ana private networks. The K 

I technology provides several aspects of security needs 

" as authentication, privacy, data integrity, and non- 

repudiation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

.,,,erent aspects of the disclosure win be .escribed 
in reference to the accompanying drawings wherein: 

,.0.. Shows an exa.plary computer networ. in accordance 

with an en^odiment of the present invention; 

f ^ PKl-based client/server 
FIG. 2 is a block diagram of a PKI base 

■ .-^.n (PBCSA) system in accordance with an 
authentication (PBCbA; !=y 

embodiment of the present invention; 
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^ oh -^C Show an authorization process 
FIGS. 3A through 3C snow <x 

.ecc..in. to an e^odi^en. .he p.esen. on, 
PM. 4 is a flowchart ot a process to bu.ld 

fn an embodiment of the 
communication privacy according to 

present invention; handshake 
FIG. 5A shows one example of a PBCSA 

1 fr^-r a Web browser client; 
protocol for a WeD handshake 

FIG. 5B shows one example of a PBCSA 

1 for a WinlNET-based component client; 
"Ti A— . Show a aetauea e.a..e techni.e 
Jlcritv .Uter in accordance with an e.o.i»ent 

the present invention; and 

,,0 , is a detailed exa^^le technrcr^e 
.tension in accordance with an e*od..ent o« the present 

0 15 invention. 

salt 

DETAILED DESCRIPTION 

™hout this description, the ---^^^ 

e.a^les shown shonld .e considered as e.a^les 

« t-he invention, 
as limitatxons of the 

;vn examplary computer network 100, 

^ • n FIG 1 in accordance with an 
is illustrated m FIG. i ^ 
internet, is lii computer network 

. ^ the present invention. The comp 
e^odiment of the p .^e computers 102 may 

100 includes computers 102, 104, 
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. omnuters" or workstations. These computers 
be ..personal computers services 
vsle users to make requests for data or 

,,^e,,,a data 

rrro—s .0. «., ...e counter 

""Trocar— a network Channel. OS, «... 

network 100 also , ^ or service between 

the requested data or servi 
allows the delivery of the req 

the computers 102, 104. 106. 

t-c -the computers 102 are client 
Xn some eu^odxments, the ^^^^ 

4-«r-<^ 104, 106 are servers, 
systems and the computers requester 
, . refers to a computer's general role 

° . , and the term "server" refers to a 

of data or services, and ^.^^ 

1. as a provider of data or services, 
computer's role as a px 

of its storage capacity and 
in terms ot its ^ 
of a computer, m affect its 

. ^..ability, does not necessarily affect 
processing capability, ,^ ,^ 

oo a client or server. 
,5 ability to act as ^.^^^ 
.csslhXe that a oo^ute, ma. re^ s^^d-^^ ^^^^^^ 

„ansaction and ^^" J^^^^ .c server or 

transaction, thus changing its 

,i,e versa. .^e computers 102 may also act as 

Tn other embodiments, the cony 

\ „ovide system administrators with access to 
_oles to provid y ^^^^ ^ ^^^^^^^^^^^ 

„d ^^^^ „etwork Channel 103. 

^ computers 102, , ^ 
in these embodiments, the con 



„ to store rei ^efer^^^ ^ 

v,<= a central se ana 

^ may b« .ication and iss 

Tuecore^ay ,uthentxca ^re 

v,e used to P^°^ ^odes, and 

also " manager 
c°««^' console, t*-- ^eaK product. 

.rti£i»'^^'' V, ,s ire Single 

S..- =0. ^„.e. 

. orator log^ ^ .^ee access to 

" the SY^""' . . featMl^^ °' the 

„ode. ' ,*ini=trat.ve es 

resources a'"^ aulhenticati ^j^^ 

1 .ore or *e »na,ed .odes . ^^^^^^^ 3 

!' core iB ^ 1 ..c.ae 

0 «nagad .ode »V 

Tbe wanay pKl'^sised 
^etv^orK. network- ^^es a 

,«OS,au*en»c- ^^^^,^„., server. 
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, i the console may create 
been authenticated, ^^^^ 
system has b ^^^^ p„bl,c key 

public/private Key pa.r ^ ^^^^.^^^ .ertidcate 

The co« may create an ■ ,„,,^tion 

.sing the Xey, and pl^ ^„,,enticatea console 

oertiUcate based np^n th ^^^^^^^^^^^ 

.ession, Managed nodes haye t ^^^^^^^^^^ 
contalnin. ..e core, pub- V^^^^^^^^^^^^^^^„,.. 
be contigured to trust ^^^^^^^ present 

oertlUcate to the mana^^ ^ ^^^^^^^^^^ 
public .ey o^ the core to yerrfy ^^^^^^^^ 
IdentiHes the ----- the certincate to 
„ode may use the information ^^^^^^^ 
,rant specie access^^^ ^^^^^ ,,,3. system 
, PKI-hased client/se ^^„,,,„„aity and the 

. , .be web seryer's extension _ .j.^ PBCSA 

utilizes the v. t'lities to implement tn 

«eb browser's script capa i ^^^^^ ,3 

p.otocol. .-c. diagram - ^^^^^^^^ 

- .agram includes the PBCS. 

,be present inyention. The ^^^^^^^^^^ ,,„,en a client 
3ystem .00 in the context ^^^^^^^ ^^^^ ...tern 
,02 and a server 204. , „eb server security 

--^-^^Trll-se'curity extension 210. 
filter 208, and a v,e 
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. nuer 208 «nitorB sessions 
„b server security also 
The web serv security £i"er 

,or proper authentication. ^^^^^^ page . 

,t unauthenticated sessions ^^^.^^ 
re-direct una interfaces a 

,he security pl«-« ^^^„,,ty piug- 

erate puWic/P"vate Key pair ■ .^e 
generate f rertificates i-J- 

also receive and store cer signatures, 
in 206 ™ay further generate 
security plug- „,i,n 210 generate 

*e cause the client 202 to 

J steps • 

„ perfor. the retired ^ an 

3 FIGS. 3^ through e*odiment of the 

S . nrocess according to includes a 

B authorisation proc ^^^^^^^^,,i„„ process mcl 

■ present invention. ^ient authorisation. 

-^^^'''^n::: si:e console su^its a re.^ - 

initially, a cl.en ^^^^^.^^ filter 

. .Ae's web server at 300. the destination 

f the token may ^n^^ t present 

.0 P«-"- °' valid security to.en is ^^^^^^ 

the console. Xf i,,tion 308 , then the 

- ' "^recTt^e reguest to the security 

""-^"T;r-gednode.s Webserver at 310. 

extension 210 of 
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direction is effected by an 
one embodiment, the re-dxrectxo 

„iate HTM. p.o.ram^ ^^^^^^^^ 

At 312, the securxty fxlte ^^^^^^ 
direct HTML program and scrip 
appropriate re-direc invocation 

206 allocs tne cx-Leiit- 
of the security plug-m ^ security 

certificate. B signature ,,,e™lned to be 

. ,i<; If the certificate 
» certificate at 3«. ^^^^^^^ ^ ^^^.ction 

T cLtV e.te.io. 3.0 the. perfor. 
session at 320. The 

^ ,^„er challenge at • ^^.^^^ect HTML program to 

v,« marts bv using the re u 
challenge may be made by ^e-direct HTML 

convey the ^ '"^^^^'J.^c.e the security plug-- 

,.ogram ^y ^^^^ the server challenge 

206 to generate tne 

challenge and the client 
f i-ViP> server chaxiexiy^ 
purpose of th ^^^^ ^^^^^^^^^^^^ 

response ie.to prevent an ^^^^^^^^^^^ 
client certificate and then ^^^^^^^^^ ^ 

in one embodiment, the s 
, .he Client may respond to the server 
„ndom nu*er. ^^^^ ^ p,i,,,e Kay 

challenge by signing the 
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associated with the session certificate. By verifying that 
the client has the private key, the server knows that the 
client is not an eavesdropper. An eavesdropper may obtain 
the certificate by listening to network traffic, but he has 
no access to the private key since the key is not sent over 
the network. 

The re-direct HTML program may direct the client to 
save the security token as a named cookie at 326. At 328, 
the client is directed to re-submit the Uniform Resource 
Locator (URL) of the originally requested page, along with a 
query string to the server. Once this process is completed, 
the security filter 208 determines if the session is 
authenticated. The determination is made using the security 
token contained in the cookie at 33 0. 

Once the session is authenticated, the security filter 
208 determines if the client is authorized to access the web 
page at 332. If authorized, the client is allowed access to 
the requested page at 334. 

FIG. 4 shows a flowchart of a process to build data 
communication privacy according to an embodiment of the 
present invention. A determination of the identity of the 
PBCSA client is made at 400. 

If the client is a WinlNET-based component, the 
security filter 208 may generate a symmetric key and encrypt 
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the key with the client's public key at 402. The filter may 
then send the encrypted symmetric key to the client via an 
hypertext transfer protocol (HTTP) header or cookie at 404. 
The symmetric key may be used to encrypt communication at 
406. If the client is a web browser, the PBCSA system may 
work with secure Sockets Layer (SSL) library 1 . 0 to provide 
communication privacy at 408. 

The combination of SSL 1.0 and the PBCSA system allows 
flexibility of an extensive client/server authentication 
without added responsibility of certificate selection and 
management . The combined system provides advantageous 
features of communication authentication and privacy at 
significantly reduced storage and management tasks for the 
client. The footprint of the server side component is 
smaller than that of a fully enable SSL 3 . 0 server. The 
PBCSA system may also provide authentication to non-SSL 
supported web servers. Further, the PBCSA system may enable 
core-based authorizations. 

FIGS. 5A and 5B show examples of a PBCSA initial 
handshake protocol. The handshake for a Web browser client 
(FIG. 5A) may start with the client first contacting the 
server with a request to an URL of the server. The security 
filter 208 then redirects the request to the security 
extension 210. The client may submit the session 
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certificate to the security extension 210. The security 
extension 210 then verifies the certificate and generates a 
server challenge. The security extension 210 redirects the 
client to its original URL. The client may then generate 
the client response and save the response as a named cookie. 

For a WinlNET-based component (FIG. 5B) , the client 
first contacts the server with the certificate inserted as a 
request header. The security filter 208 may verify and 
generate the server challenge that is inserted in the 
response header. The client may then generate the client 
response and save it as a named cookie. 

FIGS. 6A through 6E show a detailed example technique 
for the security filter 208. The duty of the security 
i filter 208 is to protect certain areas (e.g. Web pages) on 

h 15 the server by blocking unauthentic at ed or unauthorized 

i 

y client accesses. 

0 ^j^g security filter 208 waits for Internet Server 

3 Application Programming Interface (ISAPI) Uniform Resource 

Locator (URL) map notifications at 600. The filter may then 
check if the URL is protected 602. If the URL is not 
protected, the request is allowed to proceed at 604. If the 
URL is protected, the filter may check the HTTP header at 
606. 
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If the HTTP header has a HTTP_LDMSCert variable, then 
the client is a non-browser client who submitted the 
certificate in the request header. The HTTP_LDMSCert 
variable inserts the client certificate into the HTTP 
header. The variable also informs the web server that the 
connection is made by a WinlNET-based client. When the 
security filter 208 finds this variable in the HTTP header, 
the filter assumes that the connection is a new WinlNET 
connection. The filter further expects the authentication 
to take place within the security filter 208. Thus, in this 
case, the security filter 208 does not need to redirect the 
client to submit the certificate to the security extension 
210. This saves a round trip between the web server and the 
m client. 

^ ,5 The security filter 208 may then perform the 

verification of the certificate at 608. If the verification 
of the certificate 610 fails, the filter may reject the 
client at 612. If the verification succeeds, the filter may 
generate the node challenge 614 and add the challenge to the 
0 HTTP response header as a cookie variable at 616. The 

security filter 208 may respond to the client with a retry 
status at 618. The client may re-submit the request with 
the client response as the cookie variable instead of the 
certificate variable in the requested header at 620. The 
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re-submission of the request allows the client to present 
the authentication token to the server at 622. The security 
filter 208 may then create and register the session, and re- 
direct the client to the original URL. 

If the HTTP header does not have the HTTP_LDMSCert 
variable, then a check is made to find out if the client has 
presented an authentication token as a cookie variable at 
624. If the token is not present and the client is a Web 
browser 626, the security filter 208 may redirect the client 
to the security extension 210 for authentication at 628. If 
the client is not a browser, the filter may return an 
authentication failure status code at 630. The non-browser 
client automatically responds to this status code at 632. 
The client may then insert its session certificate in the 
HTTP_LDMSCert header and resubmit the request at 634. 

If the authentication token is present, the filter may 
verify that the authentication token of the client response 
is valid at 636. The security filter 208 may then reject 
the client's access at 638 if the response is not valid. 
Otherwise, if the response is valid, the filter may verify 
that the authentication token has not expired at 640. If 
the token has expired, the filter may redirect the browser 
client 642 to the security extension at 644. For a non- 
browser client, the filter may respond to the client with a 
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failure status at 646. The client may insert a session 
certificate as the HTTP_LDMSCert variable, at 648, and 
resubmit the request to the managed node upon receipt of the 
failure status at 650. 
5 At 652, Access Control List (ACL) checking is performed 

to verify that the client is authorized to access the URL in 
the manner requested. If the client passes the 
authorization process 654, the client is allowed to proceed 
to the requested page at 656. Otherwise, the request is 
10 rejected at 658. 
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FIG. 7 is a detailed example technique for the security 
extension 210. The duty of the security extension 210 is to 
obtain and verify the client's certificate when. the client 
is a Web browser. The security extension 210 may then 
redirect the client to its original URL. 

The security extension 210 may obtain the certificate 
from the' submitted form at 700. The extension 210 then 
verifies the certificate using the trusted core certificate 
at 702. If the verification fails at 704, the security 
extension 210 indicates a failure status to the client using 
an HTML program at 708. If the verification passes at 704, 
the security extension 210 creates and registers a new 
authenticated session at 706. The filter may then validate 
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this authenticated session by verifying the authentication 
token at 710. 

The security extension 210 may generate a node 
challenge random number at 712. The extension 210 may also 
5 generate the re -direct HTML program. The program may 
generate the client response and save the response as a 
browser cookie at 714, and re-direct the client to the 
original URL it requested at 716. The browser cookie may be 
saved to expire after the current session. The Web browser 
□ 10 or WinlNET component may automatically send the client 

At. 

m response as a cookie variable in subsequent requests to the 

o 



server. 

The Web browser may use the re-direct HTML program to 
redirect the browser from its requested target to the 



y 15 security extension 210 and from the extension 210 back to 
the original target during the authentication process. 

An example HTML code for the re -direct program is 
listed below. The following code segment contains HTML 
redirection scripts to redirect the client. The code 
20 contains the server challenge that may direct the client to 
invoke the security plug-in 206. The invocation of the 
security plug-in 206 calculates the client response. The 
code then saves the client response as a named cookie. The 
browser automatically submits the authentication token as 
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the cookie variable in the HTTP header in subsequent 
requests made to the server. The HTML script then redirects 
the client to the URL of the original request with the query- 
string. The original request is automatically re-submitted 
to the server with the client response after the 
authentication process. The code shown below may be found in 
the security filter 208. 



"<HTML>\r\n<BODY>Authentication in processing.. .<br>\n" 

"<OBJECT classid=CLSID:B)!B133E-E148-1 1D2-8757-00C004F72C180 height=1 id=SecCon 
width=1></0BJECT>\n" 

"<form name=\"CertData\" action=\7/jsu-deski1/MNode/idms.sec?CertVerfiy\" 

method=\"post\">\n" 
"<input type=\"hidden\" name=\"CertVerify\" value=\T >\n" 
"<input type=\"hidden\" name=\"RedirectUrl\" value=\""); 
strcat{raw, uri); 

strcat(raw, T>\n<input typ=\"hidden\" name=\"RedirectParam\" value=VT>\n <form>" 

"<script language=\"vbscript\">\n" 

"cert = SecCon.GetCert\n" 

"document.CertData.CertVerify .value = cert\n" 

"document.CertData.submitO </script>\n" 

"</BODY>\r\n</HTML>\r\n\r\n"); 
len = strlen(raw); 

pCtxt ->WriteClient(pCtxt, raw, &len, 0); 



The following code segment enables client to re-submit 
the request with the security token. The code shown below 
may be found in the security extension 210. 



STR64FromData(&digest, pSession->rdmDigest); 

_tcscpy(raw, _T("<OBJECT classid=CLSID:B)!B133E-E148-1 1D2-8757-00C004F72C180 
height=1 id=SecCon width=1></0BJECT>\n") 
_T("<script language=\"vbscrlpt\">\n") 
_T("cipherText = SectCon.GetSignedData(V"*)); 



strcpy(raw, 
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_tcscat(raw, digest); 

Jcscat(raw, _T(T)\ndocument.cookie = \AuthenBlock=KEY=")); 
_tcscat(raw, session Key); 

_tcscat(raw, _T("&CHALLENGE=\" + cipherText + \";path=A" </script>\n")); 

if (url) 

{ 

_tcscat(raw, _T("<META HTTP-EQUIV=V'REFRESH\" Conten=\"0; URL=")); 
_tcscat(raw, url); 

if (param) 

{ 

_tcscat{raw, _T("?")); 
_tcscat{raw. param); 

} 

_tcscat(raw, _T(T>")); 

} 

DWORD len = Jcslen(raw) * sizeof(TCHAR); 

pCtxt -> WriteClient(pCtxt->ConnlD, raw, &len, HSE_IO_SYNC); 



In some embodiments, an authentication connection may 
be validated each time the client sends a request to the 
server. After initial authentication, the client may 
generate the client response from the server challenge. The 
response may be sent to the server as a part of security 
token for connected session validation. In this case, it 
may be possible for an eavesdropper to get the 
authentication token by listening to network traffic. The 
eavesdropper may send requests using the intercepted token. 

To prevent this type of attack, the security filter 208 
may generate the server challenge for each request inserting 
it into the server response header. The security token 
would then be valid for only one request to the server. 

While specific embodiments of the invention have been 
illustrated and described, other embodiments and variations 
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are possible. For example, even though the present PKI- 
based client/server authentication system has been described 
in terms of client-to-server authentication, the system may 
be used to perform server-to-client authentication as well. 

All these are intended to be encompassed by the 
following claims . 
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